Transaction system for business and social networking

ABSTRACT

A wireless face-to-face bilateral communication method between at least two users of a service provider, each having a token device, and at least one having a user-defined profile, comprising: between a sending token device and a receiving token device, transmitting unique electronic transaction tokens between a consenting sending party and a consenting or optionally consenting receiving party wherein said transaction tokens may be used for single use, party-approved after-contact, computer-network facilitated access to each other&#39;s profile.

RELATED APPLICATION DATA

This application is a Continuation-in-Part of U.S. patent applicationSer. No. 11/489,435 filed Jul. 20, 2006, and entitled “ElectronicBusiness/Personal Card and Method of Use Thereof,” and claims thepriority of U.S. patent application Ser. No. 11/489,435 filed Jul. 20,2006, and U.S. Provisional Patent Application Ser. No. 60/996,307 filedNov. 9, 2007, and entitled “A Transaction Token System for Business andSocial Networking,” that are incorporated by reference herein in theirentirety.

FIELD OF THE INVENTION

The present invention relates generally to electronically aided exchangeof information between social and business contacts using controlledaccess technologies, and more particularly, to the use of tokenauthentication to control access to protected information in a contact'sprofile.

BACKGROUND

The traditional way of exchanging information between parties who are inthe same physical location is by the physical exchange of business orcontact cards. An individual who is actively engaged in any sort ofsocial or business networking will end up being encumbered by numerousbusiness cards carrying no more than names, addresses and phone numbersand no other way of actively assessing the business or socialcompatibility of the card provider and there is no active tie to theparty's online profile.

Where parties are not in the same physical location, on-line dating andsocial networking constitute internet-facilitated modalities for meetingpersons particularly in social engagements.

In on-line dating, members complete user profiles that are kept in acentral database. Users can then search the central database to furthertheir social interests. Upon identifying compatible social interests,messages are exchanged via the intermediation of the service provider.

In social-networking services, users fill out profile information thatis stored in a central database. Those profiles are associated withother users in an internodal network arrangement where each user islinked to one or more third-parties through another user with which theyhave a pre-existing personal or business relationship. Users employvarious search criteria to identify a subset of other users whom theymay be interested in meeting and are allowed to contact or view theprofiles of other users.

The key limitation of both on-line dating and social networking servicesis that both are online dominated and do not easily tie in to a user'sday to day interaction with the offline universe. In other words, cyberworld contact precedes real world contact and there is always the dangerthat the cyber profile is overly embellished and at marked variance withthe real world person.

U.S. Patent Application 20050174975 deals with a wireless communicationmethodology wherein real world contact coincides with cyber worldcontact whereby a user may access information about a specific unknownperson in their general location in order to decide whether potentialcompatibilities (either business or personal) may exist between them. Inthe '975 patent application, a methodology is described whereby a userbroadcasts a search for compatible social or business interests in theirgeneral physical vicinity, receives and electronically reviewsinformation about a potential contact within his/her vicinity andinitiates contact by sending the user's profile back to the potentialcontact, whereupon it is hoped that real world contact will then ensue.The drawback to this system is that the user spends their timebroadcasting and sifting through a myriad of online social protocols,using intelligent devices having image and data display capabilitiesrather than spending valuable time making the far more profitable fleshto flesh contact.

There is therefore a need for a wireless internet-facilitated networkingdevice and methods of use thereof wherein the real world contactprecedes cyber world contact in both social and business intercourse.For socially or professionally active individuals who meet other socialor business interests all the time, exchange of cards is often the mostconvenient way to perpetuate that contact. Even then, business cards asit were, carry very little information, often have no pictures, andremain bland and faceless long after the contact has faded from memory.In social situations in particular, cards are not often availableresulting in the inconvenience of locating pen and paper or such.Further, there is often the need to revisit and reassess the social orbusiness compatibility of a contact in a more dynamical setting.

Many electronically aided exchange of information between two previouslyunknown social or business contacts tend to be too device-dominated inthat valuable face to face time is lost viewing and classifyinginformation downloaded on the electronic device. Often, there alsoexists a need post-contact to further explore the contact in relativeanonymity before deciding to share private as opposed to public data.

Nor is social or business contact necessarily limited to naturalpersons. In bilateral exchange of information facilitated by electronicmeans, one of the parties could very much be an establishment, such as agovernment, hospital, or business or event organizer where suchelectronically aided exchange of information may be used to further abusiness purpose.

Authentication tokens have been used to promote relatively quick accessto secured data and other resources. Physical tokens include objectsthat are read by an access control device to determine whether a userpresenting the token should be given access. As the token holderapproaches or otherwise submits the token, the access control deviceinterrogates the token to make the determination.

Tokens of varying costs and complexity have been developed. Forinstance, tokens routinely incorporate cryptographic mechanisms forauthentication. Encrypted codes are commonly stored within token memoryfor eventual decryption by the access device. To this end, tokensadditionally rely on dedicated processors and/or memory for use duringauthentication. Though not necessarily used for authentication, tokensadditionally include a set of generally unalterable data that is set bymanufacturers. Such data includes serial numbers, manufactureridentifier data, time of manufacture, and/or other manufacturercontrolled information used for inventory, quality control and otheraccounting purposes.

Bilateral, per transaction, exchange of electronic or digital tokensbetween persons (natural, business or premises) desiring to furthertheir contact will provide some measure of convenience and security inaccessing each other's secured profile in a virtual environment andafford the persons opportunity to further their contact in a real worldif mutuality exists.

SUMMARY OF THE INVENTION

Embodiments of the present invention include a wireless device and a pertransaction token based system for business and social networking bynatural persons or businesses, in which actual contact precedesbilateral (or one way) exchange of tokens for after-contact, computernetwork facilitated access to each other's user profile, which mayinclude user-defined data, to be followed, optionally by furtherexchange of private data. Private data as used herein refers to anyinformation, such as profile identification, phone number, Internetaddress, contact information, financial information, or medicalinformation, which may allow perpetuation of that contact outside thevirtual token-enabled environment. As used herein, per transaction tokenis taken to mean that the token is a disposable, single-use token. Inone embodiment, the token may be of finite use rather than a single use,wherein the token may be set to expire over time or may be set to expireafter a defined incremental use.

In one embodiment, the present invention includes a wirelessface-to-face, bilateral communication method comprising a one-to-oneexchange of transaction tokens between at least one sending party and atleast one receiving party who are both registered users of a serviceprovider. As used herein, device refers to any wireless electronic tokendevice of the present invention. Where carried by a natural person, saiddevice may be any portable electronic device that is capable oftransmitting and/or receiving transaction tokens. In the case ofbusinesses, a token device may be stationary, preferably desktop device,which can communicate with an individual's portable device.Additionally, the information exchange transmission may be an intendedtransmission without the need for face-to-face proximity of one or morepreviously unknown or unconnected parties.

In another embodiment, client, a service provider's subscriber, providescredentials (e.g., username and password) for tokens to be preloaded toclient's device. Upon verification of the credentials, the serviceprovider issues to the client a plurality of digital transaction tokens.Each digital transaction token may be configured to provide proof of theclient's authorization for a social or business contact or to a businesspremise, such as an event organizer, club house, and/or hospital, toaccess the corresponding client's profile.

In one implementation, the plurality of transaction tokens may includean authentication token that is configured to provide proof of identityat the service provider's portal and which may be provided by the clientto the service provider to obtain additional transaction tokens withoutrequiring the client to resubmit credentials. An application on a clientdevice receives and loads the transaction tokens.

In one implementation, a network server generates the transaction tokensand provides the tokens to a client's device. The transaction token maybe provided by the server as part of the code comprising a profile page.

The authentication module authenticates the client's token and returnsto the requestor client, a user reply, at the option of the requestee,in the form of a profile of requestee client. In one embodiment, theauthentication module verifies that the token is being submitted by avalid user; that the received token being submitted belongs to a validrequestee and that the token is still valid, etc—and then withpermission of the requestee discloses the requestee's profile towhatever granular detail desired by the requestee. Additionally, theauthentication module may watch for the other part of the transactionpair, i.e., the user submitting the token, should also have the mirrorof the other user submitting his/her token to start the reciprocal tothe transaction.

Upon encountering a potential social or business contact, exchange oftransaction token takes place between the service clients. Preferably,the token exchange is at least a two-way exchange; however, the tokenexchange may be one way only, i.e., one client offers his/her token toanother client, while the other client does not reciprocate with his/hertoken. Subsequently, the token device application may send a profilerequest to a service provider's network server. The profile request mayinclude the transaction token optionally embedded in the profile pagecode of the requesting client rather than delivering the tokenseparately. The server receives the profile request, determines whetherthe associated token is valid, and processes the request and informs theother party that a reply profile is needed. In the preferred embodiment,the exchange between users is accomplished with only click or buttonactivation.

In one embodiment, the transaction token is embedded in profile pagecode provided in a profile response. When the profile page code isreceived and loaded by the browser application, the transaction token isloaded by the browser as well. Thus, the transaction token is optionallymaintained in the code of the profile page rather than deliveredseparately. Once the profile page and token are loaded, the browserapplication may generate a profile request in response to receivingfurther user input. The browser application then includes theauthentication token from the profile page code in the subsequentprofile request.

In yet another embodiment, once the token device has received one ormore tokens, typically at the end of the networking event, theclient-subscriber or user uploads these tokens to a data server computersystem using any suitable means of data communication such as cradles,Bluetooth, or WiFi. In a preferred embodiment, uploading to anInternet-connected computer is done via a universal serial bus (USB)interface on the wireless device In another embodiment, uploading may bedone via a wireless communication to the Internet.

In one embodiment, the tokens stored in a receiver's wired or wirelesstoken device may be uploaded to a central service which may include awebsite, a database and one or many servers. In another embodiment, theuser who has uploaded the tokens to the data server logs into a worldwide web-interface that allows them to classify their received profilesaccording to type, group, interest, and/or some other classification.Since the received profile(s) belongs to another registered user of thesystem, a picture and other general information, excluding private data,may be available to refresh the user's memory of the networkingencounter and to determine what the levels of interaction should be. Ina preferred embodiment, users may have the ability to determine thegranulation of their profile that may be seen by other users, and to setthe available channels for future communication, e.g., instant message,email, video teleconference (VTC), phone, gaming, collaboration and/orvoicemail, or none at all.

Alternate embodiments include the cases where: 1) user's devicecommunicates with the server via a cable, cradle, or other physicalconnection to a PC or other electronic apparatus which can relay tokensor other information to the server; or 2) through any form of wirelessconnection, such as Bluetooth Wi-Fi or 802.11, which may relay thetokens or other information either directly or through some intermediary(e.g., a cellular network or PC) to the server.

It is also an object of the invention to allow users in a businessnetworking contact to classify or characterize the relationship, suchthat other service-subscriber contacts can electronically access at theoption of the subscriber their business contact information, businessresume, associates, vendors, product literature, pictures, and so on.

In one embodiment of the invention, an events organizer or businessestablishment can use a stationary version of this device to gather andstore transaction tokens of attendee-subscribers of the event, uploadthe tokens and have a list of prospects to communicate relevant news andofferings or other information relevant to the event, includingconfirming the identity of the attendee. In a social networkingembodiment, a list of locations frequented or patronized or groupsjoined may be dynamically visible to one's circle of online friends.Related online profile information may be such things as name, age,phone numbers, email address, zip codes of residence, activity,interests, blogs, photos, etc., depending on the nature and the type ofthe online community or application being used.

In another embodiment of the invention, facility managers can usestationary versions of the device to register the user's attendance orinterest in a particular product or service or display. In that way, abusiness invitee can leave the location with tokens that allow access tomore information and the business establishment has acquired transactiontokens from an inquiry and prospective client.

Similarly, in another embodiment, the stationary version of thetoken-device may be built into a radio or television receiver, such thatwhen a user sends a token using a portable transaction token device, theuser receives a token from the token-transmitting-enabled radio, whichis linked within a service provider's database to communicate aparticular point in the broadcast programming, for later retrieval bythe user online. In this embodiment, it is contemplated that one of thedata objects stored in the service provider's database is a time anddate stamp for linking the transmitted token to a particular point inthe broadcast

In another embodiment, the sender and receiver's wireless devicesexchange transaction tokens using a first local wireless protocol, andthe uploading wireless device and a remote web-connected computer arecoupled together over a second wireless network.

In yet another embodiment, the present invention includes a computersystem coupled to a network, the computer system including software forperforming a method comprising storing a plurality of transactiontokens, storing profiles for one or more user-subscribers, associatingthe transaction tokens with the profile, receiving per-transactionaccess tokens from a wireless device via a computer interface andaccessing the profile associated with the one or more transactiontokens. In one embodiment, the transaction tokens and profiles arestored in a database accessible over the Internet.

In another embodiment, accessing the profile comprises generating aquery to a database using the transaction tokens and retrievinginformation associated with the transaction tokens either in response tothe query, or in a preferred embodiment, upon further action by therequestee client.

In yet another embodiment, the present invention includes a wirelesstoken device comprising an external case housing a power supply, a USBinterface, a narrow-beam send/receive hardware component, a transmitbutton, one or more confirmation light-emitting diodes (LEDs),processor, memory, USB transaction software, selector switch, a tokencounter and internal clock/calendar. In other embodiments, the device isembedded in a watch, a broach, a pendant, a necklace, a ring, anearring, an article of clothing, a clothing label, a wallet or akey-chain. In other embodiments, the device is integrated into a smartcard or the like.

The wireless token device of the present invention can be of multipleforms including ones with only the discrete functionality of the presentinvention, or integrated into or with other devices such as cell-phones,PDA's or music players either through embedded hardware or as a softwareapplication. In addition, the devices can have the capability to act asboth “sender” and “recipient” (for users interested in sending andreceiving tokens), to act only as a sender (for users not interested inreceiving tokens) or to act only as a recipient (for users who areinterested in receiving tokens). Additionally, particularly in the caseof a recipient-only device, one embodiment of the present inventionprovides that the form-factor can be such that the device appears as apiece of jewelry such as a broach, pendant, ring, earring, or as aclothing label, a key-chain, integrated into a credit-card form-factor,integrated into clothing itself or as some other fashion statement whichcan be both aesthetically pleasing and alert others that a person is auser of the system.

Additional embodiments of the present invention also include medicalapplications where a user's online profile may contain medical or otherinformation that may be accessed by a doctor, pharmacist, emergencyservices technician or other health care provider. Yet anotherembodiment of the present invention includes software, which can bedownloaded into an existing platform to enable it to practice thepresent invention and perform in the techniques described herein. Thus,in the one case, the user's medical information is stored as theirprofile and the medical facilities are given granted access byuser-initiated exchange of transaction tokens. In another case, thetransaction tokens give the medical unit confirmation of identity withintheir internal data system.

Yet another embodiment of the present invention is the use of thetransaction-token system by a retailer/business premises for targetedmarketing whereby incentives, loyalty tracking and rewards management,coupons, referrals, ratings etc are part of the retailer's applicationinterface and the consumer's user profile. Accordingly, in thetoken-enabled virtual environment, the business client always retainsthe ability to sever the business relationship or control the privateinformation available to the business.

Embodiments of the present invention also include any and all businessmethods for generating revenue and income through the sales of hardware,software and services that include one or more embodiments of theinvention described herein. These include (a) selling software for useon an existing hardware platform to enable the invention, (b) the saleof hardware (including jewelry or other form factors) to enable theinvention, (c) charging users on an annual, monthly or per-message basisfor use of the service/invention, and (d) a third party receiving links,advertorial content, or other business value in exchange for sponsoringmobile token devices or associated profile services for users. Thesebusiness methods also include the ability to charge or reward users forthe exchange of messages or information processed through one or manycentral servers based on tokens exchanged earlier between devices asdescribed above. Users of the device and service (i.e., senders,recipients, or both), may include individuals, businesses,not-for-profit organizations, advertisers, political action groups, orany other organization.

A preferred embodiment of the present invention may also include (e.g.,as part of the server) a web-based user interface for registration, andtoken and profile information management. Information managed by usersthrough this interface may include, but is not limited to, the uniqueidentifier (ID) of their mobile device, their name, address, billinginformation (if applicable), username, profile information, photo,preferences and names of friends. The user interface may also functionas a messaging center in which the user can keep track of messages sentor received as well as the profiles that they have been viewed.

Additional embodiments will be evident from the following detaileddescription and accompanying drawings, which provide a betterunderstanding of the nature and advantages of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

For the purpose of illustrating the invention, the drawings show aspectsof one or more embodiments of the invention. However, it should beunderstood that the present invention is not limited to the precisearrangements and instrumentalities shown in the drawings, wherein:

FIG. 1 illustrates a computing environment and an example of auser-level process of the token-exchange, record, and clarificationevents, according to one embodiment of the invention;

FIG. 2 illustrates a computing environment and an example of adata-level process of the token-exchange, record, and clarificationevents, according to one embodiment of the invention;

FIG. 3 illustrates a computing environment and an example of a tokengeneration process according to one embodiment of the present invention;

FIG. 4 illustrates a computing environment and an example of a processfor authenticating and processing a profile request;

FIG. 5 illustrates a token process flow according to one embodiment ofthe present invention;

FIG. 6 illustrates a top view of a pair of portable token devices thatare communicating in a wireless fashion, in accordance with oneembodiment of the present invention;

FIG. 7 illustrates a functional block diagram of a portable token devicethat is coupled to a host device in accordance with one embodiment ofthe present invention;

FIG. 8 illustrates a functional block diagram of a secure data retrievalsystem that uses non-secure tokens in accordance with one embodiment ofthe present invention;

FIG. 9 illustrates a top view of a pair of portable token devices thatare communicating in a wired fashion, in accordance with one embodimentof the present invention;

FIG. 10 illustrates a functional block diagram of a portable tokendevice that includes ultrasonic communication capability, in accordancewith one embodiment of the present invention;

FIG. 11 illustrates a functional block diagram of a portable tokendevice that includes wireless broadband communication capability, inaccordance with one embodiment of the present invention;

FIG. 12 illustrates a functional block diagram of a portable tokendevice that includes sound recording capability, in accordance with oneembodiment of the present invention;

FIG. 13 illustrates a functional block diagram of a token exchangeenvironment, which includes a third party device that may serve as anintermediary device for the exchange of information between two or moreuser-subscribers;

FIG. 14 illustrates a functional block diagram of a token exchangeenvironment, which includes another third party device that may serve asan intermediary device for the exchange of information between two ormore user-subscribers;

FIG. 15 illustrates a functional block diagram of a computingenvironment that includes a plurality of service providers, rather thanone service provider only;

FIG. 16 illustrates a process of conveying the profile information thatis associated with a transaction token, rather than displaying theprofile information only;

FIG. 17 illustrates a functional block diagram of a computingenvironment that includes token devices that are associated with acomputer network address, rather than with a user profile, and

FIG. 18 illustrates a functional block diagram of a telephone-basedtoken system.

DETAILED DESCRIPTION OF THE INVENTION

In the following description, for purposes of explanation, specificdetails are set forth in order to provide a thorough understanding ofdifferent aspects of the present invention. It will be evident, however,to one skilled in the art that the present invention as defined by theclaims may include some or all of the features or embodiments hereindescribed and may further include obvious modifications and equivalentsof the features and concepts described herein.

Embodiments of the present invention use wireless protocols and networksfor implementing novel methods and algorithms that obviate the need fornon-electronic business and contact cards and allow users to liberally,confidently, and anonymously distribute and gather per-transactionaccess tokens for use in later classifying and perpetuating the contactat the option of the user-subscriber. Additionally, the per transactiontoken offers a severability function that allows users to confidentlyqualify their contacts in a virtual environment and then decide whetherto continue or terminate the exchange by denying or granting privilegesto real-world contact information.

As used herein, profile refers to any information or resource about theuser-subscriber and includes a wide range of resources (e.g., servicesand content) via a network. For example, profiles may include, but arenot limited to, web pages, contact information, schedules, links,friends, activities, social affiliation, feeds, blogs and anycombinations thereof. Additionally, profiles may contain tools thatallow users to engage in communications via email or instant messaging,photos, use applications, and so forth. In a business setting, profilesmay also include, but are not limited to, purchase history, interests,receipts, loyalty points, coupons, referrals, business or system ratingsthat allow a receiver to make decisions about a product or vendor basedon transaction feedback or other system metrics, and so on. In apreferred embodiment, profiles may simply be access means to othercommunication channels, public or private, or access to health orfinancial information.

In the case of a business, a profile may include any business ormarketing communication, such as product description, business resume,video clip, coupons, receipts, targeted advertisement, event promotion,targeted solicitation, and the like. A profile may be completely virtualin the sense that nothing in the profile bears the real identity of theprofile owner. This feature allows the contacts to communicate invirtual anonymity and decide whether there is mutual need to perpetuatethe contact by exchanging a real profile, such as a profile thatcontains private data. Alternatively, at least one contact may have avirtual profile while another contact may have a real (or non-virtual)profile.

FIG. 1 illustrates a computing environment 100 and an example of auser-level process of the token-exchange (e.g., for business and socialnetworking), record, and clarification events, according to oneembodiment of the invention. As shown in FIG. 1, a User A and a User Bmeet at a networking event and exchange transaction tokens over an adhocor pre-established communication channel 110. Subsequently, thetransaction tokens are uploaded to a network computer by which arequestor profile and the received tokens of the requestee may be passedonto to a service database in order to prompt a reply profile from therequestee. A reply profile may cause the original requestor to beautomatically logged out of the requestee's profile after apredetermined period of time or at the instruction of the requestee. Aprofile may also include a webpage that is associated with therequestee's profile, where at least a portion of the content of thewebpage is based on the authorization status embedded in the tokenand/or the authorization status of the requestor. Also, the replyprofile may be a second webpage that has an embedded portion that allowsthe requestor to log on to an authentication system. In a preferredembodiment, tokens are single-use and are not redistributable from theauthorized recipient to another. Further, tokens may be set to expireover time. Tokens may also be of longer duration or fixed to be used inmultiple transactions.

Referring to FIG. 1, the reply profile may include messages from therequestee. In one embodiment, User A may re-direct communication withUser B to another communication channel. User B may be allowed tocommunicate with a User C (not shown) on the second communicationchannel without receiving private data about User C.

The token device may be configured in a variety of ways for accessingthe service provider's network. For example, one or more of the tokendevices may be configured as a computing device, such as a desktopcomputer, a mobile station, an entertainment appliance, a set-top boxthat is communicatively coupled to a display device, a wireless phone, agame console, and so forth. Thus, the token device may range from fullresource devices that have substantial memory and processor resources(e.g., personal computers, game consoles) to low-resource devices thathave limited memory and/or processing resources (e.g., traditionalset-top boxes, hand-held game consoles, key fobs). Preferably, theportable token device (e.g., token devices 210A and 210B of FIG. 2) ofthe present invention for use by individuals is a low-resource devicewithout display capabilities, so that exchange of tokens may occurwithout tempting the user to spend valuable face to face contact timescrolling through displays.

FIG. 2 illustrates a computing environment 200 and an example of adata-level process of the token-exchange (e.g., for business and socialnetworking), record, and clarification events, according to oneembodiment of the invention. In particular, FIG. 2 illustrates anembodiment of a computing environment for implementing the presenttechnology. The computing environment shows a network 260, which,preferably, may be the Internet. However, network 260 may assume a widevariety of configurations. For example, network 260 may include a widearea network (WAN), a local area network (LAN), a wireless network, apublic telephone network, an intranet, and so on. Further, network 260may be configured to include multiple networks. For instance, a clientmay be communicatively coupled via a peer-to-peer network with anotherclient. Each of the clients may also be communicatively coupled to theservice provider's authentication module over the Internet. A variety ofother configurations are also contemplated.

The system may include one or a plurality of application modulesproviding for instance, the ability of the users to switch over from avirtual environment to another communication channel. Applicationmodules are executable to provide a variety of functionality torespective clients. For example, one or more of application modules maybe configured to send and receive email. In yet another example, one ormore of application modules may be configured to send and receiveinstant messages. And in yet another example, the system may allow atoken to pass over an established communication channel, such as email,text messaging, web interface, and/or phone, so as to allow the users toreconnect in another communication channel via the token environment.

Additionally, a wide range of functionality may be made available toclients from one or more service providers as part of their profile. Theresources, for instance, may be configured as a variety of content, suchas web pages, music, video, images, user forums, templates, add-ins, weblogs (i.e., blogs), and so forth. Further, service providers may provideresources which are services, such as instant messaging service, emailservice, financial service, collaboration environments and so forth. Forexample, plurality of services may include a web search service (e.g., asearch engine) that is provided to search the Internet, an email servicethat is provided to send and receive email, an instant messaging servicethat is provided to send instant messages between the clients, and soon.

FIG. 3 illustrates a computing environment 300 and an example of a tokengeneration process according to one embodiment of the present invention.A network server generates the transaction tokens. The tokens may begenerated by the network server in response to a request from a clienttoken device (for example, a login request). After generating thetransaction token, network server provides the token to the clientdevice. In a preferred embodiment, a token is generated and requested byan authenticated user that is logged onto the service provider'swebsite. Tokens generated by the network server may be derived from orassociated with a token device ID and/or user ID, or some other portionsof the user profile, e.g., an email address or a phone number.

In one embodiment, a client executes an application module, whichgenerates a request to an authentication server. The request may beconfigured to seek authentication and a plurality of transaction tokens.The authentication service authenticates the request using credentialsof the user. The authentication service, in response to the request,provides the user with one or more single use transaction tokens, eachof which may then be transmitted to a social or business contact for usefor party-approved access to the client's corresponding user profile. Inthe preferred embodiment of the stationary token device that is locatedin a business/premises with which a business invitee exchanges tokens,the stationary device is expected to maintain a live connection to theservice provider database that then returns the identity, perhaps apicture, for two-factor security and an approval code of some kind.

FIG. 4 illustrates a computing environment 400 and an example of aprocess for authenticating and processing a profile request. Postcontact, the request for another party's profile is made and saidrequest is received and loaded by a browser application communicativelylinked to the token device. Upon receiving subsequent input, where userinput is prompted, the browser application may send a reply profile tothe requesting client via the server. The profile request includes therequestee's transaction token that is uploaded to the browserapplication. The server receives the request having the transactiontoken and determines whether the token is valid. If the received tokenis valid, a reply profile is generated, automatically or uponrequestee's approval, and sent to the requesting client. If the token isnot valid, the requested profile is not provided to the client.

One embodiment of this invention uses a token that requires a one-timetransaction encryption. A one-time transaction algorithm generates apassword that can be used once only to authenticate a request for theother party's profile. In another embodiment, passwords, user names,and/or other data is used in addition to the device ID, such as serialnumber or manufacturer ID, as controlled information for realizing tokenauthentication. In one such embodiment, the password is stored in thetoken and is automatically transmitted to the token device, possiblyalong with the user ID.

In the preferred embodiment, a given token can be passed once only so asto protect the authenticity of the exchange. To preserve transactiontoken uniqueness, the token generation server may keep a record oftokens as they are issued to users and as they are returned by contactswith whom they are exchanged. As tokens are submitted with requestprofiles, the authentication server is then able to (1) ensure that thegiven token is valid and (2) ensure that the token has not beenpreviously uploaded.

The authentication service may comprise an authentication module and aservice module. Authentication module is representative of functionalitywhich may be utilized in order to authenticate a client, which mayinclude verification of client credentials. Authentication module mayalso comprise client credentials that correspond to respective clients.Client credentials may be used to verify that the clients “are who theysay they are” or in other words authenticate the client's identity. Theclient credentials, for example, may be a user name and password that issupplied by the client. Other client credentials are also contemplated,such as a shared secret, biometric, an encryption key and so forth.

A profile module comprises the functionality that may be utilized todetermine profile granulation and which granulated profile aclient-contact having the requestee's token is authorized to access. Forinstance, a profile module of an authentication service may beconfigured to generate reply profiles that grant access to or re-directthe other party to another communication channel. See FIG. 4.

Naturally, functionality for authentication, token issuance, profilegeneration, and so forth may be divided differently among variousmodules of authentication service in different implementations withoutdeparting from the spirit and scope thereof.

Generally, any of the functions described herein can be implementedusing software, firmware (e.g., fixed logic circuitry), manualprocessing, and any combinations thereof. The terms “module,”“functionality,” and “logic” as used herein generally representsoftware, firmware, or a combination of software and firmware. In thecase of a software implementation, the module, functionality, or logicrepresents program code that performs specified tasks when executed on aprocessor (e.g., central processing unit (CPU) or CPUs). The programcode can be stored in one or more computer readable memory devices. Thefeatures of the transaction token techniques herein described areplatform-independent, meaning that the techniques may be implemented ona variety of commercial computing platforms having a variety ofprocessors.

Regarding implementation, the authentication module, when executed on aprocessor of server, authenticates an authentication request that issent by a client seeking transaction tokens. For instance,authentication of a request may include accessing and verifying the trueuse of client credentials. The plurality of client credentialscorresponding to a plurality of clients are maintained in storage ofmemory provided on the server. It is noted that credentials may bemaintained on another server of the authentication service or otherwiselocated remotely in storage. The credentials that are located remotelymay be accessible via network.

Credentials indicated in the authentication request may be checkedagainst credentials stored by the authentication service to authenticatethe request. In general, credentials are verified by comparingcredential information (e.g., name and password) that is provided by theclient with client credentials that are accessible to the authenticationservice (e.g., stored in memory). Client credentials may be verifiedusing numerous authentication schemes, such as by challenge/response,digest, negotiate, NT LAN Manager (NTLM), kerberos, basic (clear text),and so forth. This may include transferring credentials (e.g., cleartext) between client and server via the network. Alternatively, a schemein which user credentials are not sent over the network (e.g.,challenge/response) may be used for enhanced security.

Once the authentication request, preferably configured to seek multipletransaction tokens, is authenticated, authentication service is furtherconfigured in order to generate a response that corresponds to therequest for communication to the client. In particular, the responsesare configured to deliver a plurality of transaction tokens in a singlerequest and response round trip between a client and an authenticationserver. In other words, a plurality of transaction tokens may beobtained in a single transaction.

Naturally, the set of tokens that are requested and received may beconfigured in a variety of ways. The set of tokens requested andreceived in a transaction may be specified by default, for instance, inthe default configuration of an application module. Further, an optionmay be provided to a client for specifying which tokens to obtain in anauthentication transaction, e.g., one requiring input from requesteebefore a reply profile is sent, one that sends a reply profileautomatically without further input from the user, and/or a token thatdegrades over time. Accordingly, the token device may optionally containa switch to select which type of token is to be delivered on a givenoccasion.

FIG. 5 illustrates a token process flow 500 according to one embodimentof the present invention. In one example, token process flow 500 mayinclude, but is not limited to, the steps of the user installing thedevice (Step 501) or connecting it to the network. The use logs on thedevice to reach the authentication server (Step 502), the authenticationserver verifies the user's account (Step 503). Once a trusted connectionis created between the token device and the authentication server, theauthentication server generates a token that are associated with theuser's profile account and sends the token to the device (Step 504). Thedevice loads the token therein (Step 506). In one embodiment this may beby plugging a USB into computer or authenticating a mobile phone to thetoken/identity server. Next, depending on the platform the user may berequired to credential themselves to the system along with the device sothat the identity value of the token device is maintained.

In the face to face interaction, one embodiment of the token processflow in FIG. 5 would continue with the respective users pressing abutton or buttons to initiate the transmission of their tokens (Step506) and the receipt of the respective user's transmitted token (Step507). At this point each token would be stored in the device memory(Step 508) for subsequent upload to the authentication server (Steps509-510). Depending on the platform may happen automatically in the caseof a mobile Internet attached device or require a similar interface toStep 2 and 3 and again ensure trusted communication between the tokendevice and the identity authentication server.

The last portion of the token flow process under one embodiment would bewhere the users process the relationship connection between them by thesystem verifying the authenticity of the two-way exchange (Step 511),then the person to person approval of the connection (Step 512) and thenthe ongoing communication that may occur (Step 513). In a secureconnection the final step with the token server would be to deactivatethe particular tokens (Step 514) as a method for ensuring that eachtransaction is unique in the token address space.

FIG. 6 illustrates a top view of a pair of portable token devices, suchas token devices 210A and 210B of FIG. 2, that are communicating in awireless fashion, in accordance with one embodiment of the presentinvention. Each token device 210 may be formed of a housing 220 thatincludes a transmit button 222 for activating data exchange (e.g., forexchanging tokens), an LED 224 (e.g., a confirm data exchange LED), awireless interface 226 (e.g., a window for sending and receiving shortbursts of data to/from a sister device via, for example, aninfrared/radio frequency (IR/RF) emitter), a token counter meter 228,and a hardware interface 230 (e.g., a USB port). The housing 220 oftoken device 210 may include an opening 232 for installing, for example,a ring 234 therethrough. In one example, ring 234 may be used forattaching token device 210 to a user's key ring.

FIG. 6 shows wireless data exchange between token devices 210A and 210B,which are preferably less than about five feet apart and generallypointed at one another. In another embodiment, the uni-directiontransmission range may be extended to about 30 to about 40 ft such thata passive device may receive IDs from interested parties within sight,but not within conversational distance. However, the exchange of tokensmay occur over any type of channel, such as wireless data, analog voice,Short Message Service (SMS), email, instant message, and/or IntegratedServices Digital Network (ISDN).

FIG. 7 illustrates a functional block diagram of a portable tokendevice, such as token device 210, which is coupled to a host device,such as network computer 250, in accordance with one embodiment of thepresent invention. FIG. 7 shows that token device 210 may includetransmit button 222, LED 224, wireless interface 226, and hardwareinterface 230, as described in FIG. 6. Additionally, token device 210may include a system clock 236 for marking received and/or transmittedtokens with a timestamp of the event. Comparing the timestamps of thereceived and/or transmitted tokens may be used by the system toauthenticate and/or verify the networking contact. This may also provideverification within the database that the token was delivered during itsallowed token lifetime. It may also be used as means for organizingcontacts. In other applications, such in a radio or broadcastenvironment, wherein a user exchanges tokens with a broadcast device,the time stamp may allow the requestee to vary the reply profile basedon the timestamp of the transaction.

The token device can have various other components including, forexample, a processor 238, biometric components 240, and a power source242. Processor 238 may be any controller, microcontroller, or DSPdevice. Biometric components 240 may include, for example,fingerprinting, a breath analyzer, and/or a retina scanner. The portabletoken device can be in the form of a USB device, a Smart Card, or othereasily portable small embedded device. In general, the portable tokendevice, as opposed to a premises/retailer desk-top token device, mayoperate without a keyboard, a display screen, or other input/outputfunctionality.

In one embodiment, the biometric element may used to verify the rightsof the user to operate the token device. In another embodiment, thebiometric element may be used to verify the permission rights of theuser to the token service provider or to a third-party for the purposesof conducting a token related transaction.

A memory 244 of token device 210 can include, for example, read-onlymemory (ROM), Flash memory, and/or random access memory (RAM) inaccordance with various embodiments. Memory 244 may include one or morephysical memory storage devices and/or memory that is directlyassociated with a processor circuit, such as a circuit of processor 238.Stored on memory 244 may be, for example, a device ID 246, one or morepreloaded tokens 248, one or more received IDs/tokens 252, and a dataserver internet address 254.

In contrast to many USB devices, the portable token device includesprocessor 238 for running token device applications on portable tokendevice 210. Processor 238 of token device 210 may be a specializedmicro-processor in accordance with one embodiment. Optionally, tokendevice 210 may include a secure processor that runs an operating systemor a specialized secure micro-processor that is designed for running aspecialized application.

Referring to again FIGS. 6 and 7, token device 210 may include hardwareinterface 230, which may be, for example, a USB interface, a Smart Cardinterface, or network interface. Hardware interface 230 may be a wiredor wireless interface in accordance with various embodiments. Hardwareinterface 230 provides I/O functionality between the host device, suchas network computer 250, and the portable token device, such as tokendevice 210. Additionally, in some embodiments, power may be providedfrom the host device to the token device over hardware interface 230.Alternatively, the token device includes an on-board power source, suchas power source 242, which may be, for example, a battery or solar cell.Other functionalities not shown in the FIGS. 6 and 7 may include areceived token and a to-be transmitted token.

Additionally, the token device 210 that is shown in FIGS. 6 and 7 isexemplary only and not limited to the components and/or functionalityshown. For example, in another embodiment, LED 224 and hardwareinterface 230 (e.g., USB interface) may be optional. In this example,alternative data exchange confirmation is optionally provided andwireless interface 226 may be used to communicate with an externalhardware device instead of hardware interface 230. Furthermore, otherexample embodiments of token devices are described with reference toFIGS. 9 through 18.

While more sophisticated tokens known in the art may be used inaccordance with the principles of the present invention, so-called“dumb” tokens, such as any unique digital string may suffice. As such, atoken device for purposes of the invention may include any portabledevice having computer-readable manufacturer controlled information.Where desired, the token device may include a processor. Alternatively,instead of the token being an entirely unique digital string, the tokengenerator may generate certain tokens that have a portion only of thedigital string that is unique. The software for accepting/identifyingthe transmission may be adjusted accordingly.

Device ID 246 that is stored in memory 244 may be a fixed unique deviceID, such as a unique serial number or manufacturer ID or a profile IDwithin the profile database. As is the case of Ser. No. 11/489,435, thetoken of these embodiments may be entirely derived from more bits ofinformation. Alternatively, in another embodiment, token device 210 mayinclude a built-in random number generator (not shown) for generating aunique device ID. For example, an algorithm for random number generationmay be implemented in processor 238.

The token device may include its own receiver, such as a token receiver256, and/or transmitter, such as a token transmitter 258. Suitabletokens devices may passively or actively transmit tokens. Rather thanpreloading tokens, such as preloaded tokens 248, from a server, a tokendevice of the present invention may be programmed to internally generateand store tokens so that a given user may have a queue for to-betransmitted tokens (not shown) and another queue for received tokens,such as received ID/tokens 252. Token devices that are capable ofinternally generating tokens may include memory having random code, suchas a random diversifier, which may be used independently of anymanufacturer-controlled data to generate a cryptographic key. The keymay alternatively be supplied by the token server or may be capable ofbeing recognized by the token server.

In terms of mobile token exchange between social or business contacts,any appropriate wireless signaling protocols may be used to exchangetransaction tokens. However, it is preferred that transaction tokens beexchanged between mutually consenting parties. Alternatively, aconsenting sending party transmits his/her token to at least onereceiving party that may optionally consent to the token exchange.Infrared transmission may be to a certain extent directionally specific(e.g., between one intended user and another), short range, and can beimplemented by any signaling methods known in the art, for example, asthose described on the website of the Infrared Data Association.Alternatively, a short range RF signaling protocol may be used totransmit the tokens from one user to another, e.g., Near-FieldCommunications (NFC) such as those discussed online at the Near FieldCommunication Forum. NFC is of particular value because the specificcommunication is established by physical proximity—inches in the case ofNFC.

The preferred mode of communication between the devices is a wirelesssignal sent between one sending and one receiving device. Since theintent is to support one to one personal contact, the design is such asto prevent the exchange of IDs other than to/from the intendedphysically proximate party. The same or different wireless technologymay be used for a reply made by the receiving device to the sendingdevice. However, embodiments of the presented invention are not limitedto any specific currently existing or future wireless technologies.Additionally, the communication between the devices is not limited towireless communication. For example, more details of an example of wiredcommunication between devices is described with reference to FIGS. 9through 18.

As illustrated in FIG. 2, the token devices, having no displaycapability, may upload the received tokens to a computer systemconnected to the network 260. Computer system 290 may be an Internetserver computer and may include multiple computers coupled to theInternet for processing information as described herein, for example,and may further include a web application 270 having a user interfacethat allows users to update their profile, store, classify, and organizetheir portfolio of profiles. Computer system 290 may provide access tofurther information about the user of the sending device or other usersthat are associated with the tokens received from the sending device.Furthermore, computer system 290 may act as a central storage locationfor user information as well as a clearinghouse and delivery system formessages sent between users.

An additional embodiment of the present invention includes the use ofthe service and/or hardware for the electronic commerce applicationsincluding micropayments. Micropayments are prepaid accounts that may beused for low dollar amount purchases.

The method of the present invention can be adapted for secure dataretrieval system in a business context using non-secure tokens whereinone of the registered users is a business premises, event organizer orhealth-care provider having a display-capable stationary transactiontoken device, said stationary token device capable of real time downloadand display of profile associated with received transaction tokens andwherein business data associated with owner of said profile may besecurely accessed to facilitate a business transaction.

FIG. 8 illustrates a functional block diagram of a secure data retrievalsystem 800 that uses non-secure tokens in accordance with one embodimentof the present invention. By way of example, secure data retrievalsystem 800 may include medical applications where a user profile maycontain medical or other information that may be accessed by a doctor,pharmacist, emergency services technician or other health provider. UserA, an individual and a business client or invitee having a portabletransaction token device 210A exchanges token with a stationarytransaction token device 805 situated in a hospital or businesspremises. The stationary token device 805 requests User A's profile froma system database 820 using the token received from User A. User A'sprofile downloaded into the stationary token device 805 may include UserA's picture, e.g., photo A. Upon verification that the token isassociated with a user that has an account in the other party's system,that verification code can be fed, for example, to an external device810 (e.g., point of sale, security gate, medical device, etc) of thevendor along with perhaps the account code and the client's officialpicture in order to retrieve their business or medical records from thevendor's database, such as an external database 830. In that way, asystem more secure than the typical credit card has been created becausethere is no credit card number in circulation (given that tokens aresingle use) and the vendor received picture verification that the tokenbelonged to the holder. The retrieval of a user picture verified by atrusted authentication service, e.g., a government office or a bank,based on the submission of a token according to these methods, creates amultitude of secure access applications similar to the premise purchaseapplication descriped here.

Referring again to FIG. 8, one benefit of the index of the externaldatabase 830 may be in enabling e-commerce. For example, one method ofenabling e-commerce with the token devices is to have the user entertheir credit card information into their profile. Then whenever a useruses his/her token device at a payment station (e.g., a point of sale(POS) device), the station submits the payment amount along with thetokens for authentication and processing. In this environment, theservice provider must securely store all of the associated financialaccount information. The index of the external database 830 of securedata retrieval system 800 is suitable for this purpose.

In one example, the service provider may store a reference only to theuser's bank account on the external database 830. Then over the securechannel they inform the associated vendor which of their clients ismaking the request. One advantage of the architecture may be that theseindexes may be updated as often as the vendor wants, and are of no useoutside of the secure channel between the service provider and externaldatabase 830. In turn the account numbers are also protected, becausethey never need to be revealed publically in order to conduct atransaction and, thus, are protected from being stolen and used in anunauthorized fashion. Another privacy benefit of the index of theexternal database 830 is that every bank/vendor may have their ownreference index within the system, without relying on, for example, asocial security number to keep the information aligned.

Yet another embodiment of the present invention includes software, whichcan be downloaded into an existing platform to enable it to practice thepresent invention and perform in the techniques described herein.

Embodiments of the present invention may also include business methodsfor generating revenue and income through the sales of hardware,software and services using the techniques described herein. Theseinclude, but are not limited to, (a) selling software for use onexisting hardware platforms to enable the invention, (b) the sale ofhardware (including jewelry or other form factors described below) toenable the invention, (c) charging users on an annual, monthly orper-message basis for use of the services described herein, and (d) athird party receiving links, advertorial content, or other businessvalue in exchange for sponsoring mobile token devices or associatedprofile services for users. These business methods also include theability to charge or incentivizing users for the exchange of messages orinformation processed through one or many central servers based ontokens exchanged between mobile devices and then uploaded as describedabove. It is to be understood that a variety of users (i.e., senders,recipients, or both) may benefit from various applications of thepresent invention. Users of the devices and services may includeindividuals, businesses, not-for-profit organizations, advertisers,political action groups, or any other organization.

In a preferred embodiment, the token device is ruggedized by any meansknown in the art so that it can withstand the jostle and tumble ofeveryday life. The wireless token device of this invention is preferablya portable stand alone device having no display capabilities preferablyweighs less than one ounce. It may be embedded in a watch, a cell-phone,a broach, a pendant, a necklace, a ring, an earring, an article ofclothing, a clothing label, a wallet or a key-chain.

In another embodiment, the hardware interface of the device may have aretractable, foldable, or otherwise physically protected male USBinterface, such that the device can quickly interface to a computer. TheUSB interface shall be discrete and protected when not in use. Also, inone embodiment, the wireless interface of the device may have an IR/RFemitter for sending and receiving short bursts of data to/from a sisterdevice. In a preferred embodiment, the transmitter may usedata-transmission protocols that are suitable for successful delivery of512 bits of data. The device shall have a single button to activate theIR/RF send/receive function and the exchange of wireless identificationsshall be accomplished by single button exchanges so that the flavor ofthe moment is not diluted by multiple clicks and button exchanges. Whenpressed, the emitter shall transmit a single token. It may be that ifthe transmit button is held down longer than, for example, about 15seconds it will need to be released and re-pressed for the device tobegin the cycle again. It is to be understood that longer or shortertransmission times are part of the invention. In the stationaryembodiment, the device may be set to always receive via an on/offswitch.

While the device is transmitting data using the IR/RF interface theLED(s) may use a signal pattern (e.g., blinking) to indicate to the userthe device's activity. When the RF receiver successfully receives datafrom another device the LED may show an alternate signal pattern (e.g.,solid for 2 seconds) to indicate the reception. Also, devices shall havean internal processor to control the interaction of the variouselectronic components, including, but not limited to, the inter-devicesignaling protocol (IR or otherwise), error checking to prevent multiplecopies of the same data being written successively, the LED signalpattern, the USB upload protocol, the initial process of linking thedevice to the data server and assigning or registering it's unique ID,and the initiation process of the device to upload the particular usersprofile to the data server.

FIGS. 9 through 18 below describe additional embodiments of tokendevices and systems of the present invention.

FIG. 9 illustrates a top view of a pair of portable token devices 910that are communicating in a wired fashion, in accordance with oneembodiment of the present invention. Portable token devices 910, such astoken device 910A and 910B, are substantially the same as portable tokendevices 910 that are described in FIGS. 2 through 7 except that a wiredcommunication means for communication between portable token devices 910is provided in place of or along side of, for example, wirelessinterface 226 (e.g., an IR/RF emitter). In this embodiment, each tokendevice 910 includes a female USB connector 920 and a male USB connector930. Therefore, the exchange of tokens may be facilitated in a wiredfashion by directly coupling the male USB connector 930 of one tokendevice 910 (e.g., token device 910A) to the female USB connector 920 ofanother token device 910 (e.g., token device 910B), as shown in FIG. 9,and pressing the transmit button 222. Optionally, a removable cap (notshown) may be provided for protecting male USB connector 930 when not inuse.

Portable token devices 910 are not limited to the use of USB connectorsfor providing the wired communications, as shown in FIG. 9. Anyconvenient mechanism for providing a direct electrical connectionbetween two token devices is suitable. For example, two or more flatcontact pads (e.g., spring-loaded contacts) may be provided on thehousing of each token device, where the contact pads of one token devicemay be held against the contact pads of another token device by theusers thereof. In this example, a simple alignment mechanism may beprovided to assist contact.

FIG. 10 illustrates a functional block diagram of a portable tokendevice 1010 that includes ultrasonic communication capability, inaccordance with one embodiment of the present invention. In thisembodiment, portable token device 1010 is substantially the same asportable token device 210 of FIGS. 2 through 7 except that an ultrasonicdata communication module 1020 may replace or operate along side ofwireless interface 226, in order to provide a portable token device thatuses ultrasonic data as the wireless data transfer mechanism.

Ultrasonic data communication module 1020 may include any suitablecomponents for transmitting/receiving acoustic waves, such astransducers for converting electronic data to pulsed ultrasonic data andvice versa. In one example, FIG. 10 shows that ultrasonic datacommunication module 1020 may include an acoustic transmitter 1030 andan acoustic receiver 1040, both of which may be transducer devices. Thedata transmitted and received by acoustic transmitter 1030 and acousticreceiver 1040, respectively, may be processed by, for example, a digitalsignal processor (DSP) 1050. An example of technology that is suitablefor use in ultrasonic data communication module 1020 is found inreference to U.S. Pat. No. 5,982,297, entitled “Ultrasonic datacommunication system,” assigned to The Aerospace Corporation (ElSegundo, Calif.). The '297 patent describes a system that includes afirst transducer and a second transducer that are coupled togetherthrough a coupling medium that communicates input and output undulatingpressure waves between the first and second transducers. In this way,input and output data is transferred between an external controller andan embedded sensory and actuating unit. The external controller providesinput data signals that energize the first transducer and the embeddedunit that provide output data signals that energize the secondtransducer collectively for bidirectional communication of data betweenthe controller and embedded unit for functional sensor and actuatorprocess control. The system of the '297 patent provides bidirectionaltransfer of data through a coupling medium without the use of electricalpower wires for controlling embedded sensors and actuators.

Referring again to FIG. 10, in the token exchange operation, pulsedultrasonic data is transmitted/received by use of ultrasonic datacommunication module 1020 within the token device in order to providewireless bidirectional data transfer. In this embodiment, the use of thetoken device is to some extent directional, meaning the user of thetoken device must point his/her token device in at least the generaldirection of another token device of interest.

In another embodiment, the portable token device of the invention mayinclude wireless broadband technology, such as Wi-Fi technology, IEEE802.11 technology, ZigBee® technology, and/or Bluetooth® technology,that enables wireless communication via, for example, a wireless WANand/or LAN. The inclusion of broadband technology in the portable tokendevice allows for device-to-device and/or device-to-networked computercommunication, an example of which is shown in FIG. 11.

FIG. 11 illustrates a functional block diagram of a portable tokendevice 1110 that includes wireless broadband communication capability,in accordance with one embodiment of the present invention. In thisembodiment, portable token device 1110 is substantially the same asportable token device 210 of FIGS. 2 through 7 except that wirelessbroadband technology 1120 may replace or operate along side of tokenreceiver 256, token transmitter 258, and wireless interface 226.

In the case where there is a party line or broadcast or medium/meetingroom wherein two or more users wish to exchange tokens with each other(e.g., a one-way or two-way exchange). The devices may be put into adiscovery mode to identify all of the other token devices in the spaceor communications channel, before beginning token transactions with eachof the discovered devices. Such bounded discovery operation may becontrolled based on signaling range, a select channel, a shared secret,a user selection interface or other means to prevent unauthorizedpersons from participating in the group token exchange. In a physicalmeeting space, this token method avoids the archaic business cardexchange ritual at new meetings.

Because wireless broadband technology 1120 may allow a certain tokendevice to discover multiple other token devices that may be also withinthe range of a wireless broadband network, an additional operation maybe required to establish a one-to-one connection. That is, another levelof functionality and/or navigation may be required. For example, thetoken device may be equipped with a small display and/or keypad. In oneexample, once a certain device queries the wireless broadband networkand discovers multiple token devices, a set of pictures of all thediscovered users may be displayed. The user of the certain token devicemay then scroll through the user pictures and select one or more usersof interest with whom to exchange tokens.

Another method of communicating with one of several users that have beendiscovered may be by transmitting a mutually known code between at leasttwo consenting parties. Upon the two or more token devices detectingmatching codes, the at least two consenting parties may perform aone-to-one exchange of tokens. Any of various methods of generating acode may be utilized. In one example, the sender presses a certainnumber sequence on a keypad of his/her token device, which istransmitted over the wireless broadband network. Alternatively, thesender presses a certain key (e.g., transmit button 222) multiple timeswith a certain sequence of short and long pulses, like Morse code. Alldevices within range of the network may receive the code. However, thecode is known to a certain one or more intended receivers only who mustact to enter the same sequence, perhaps within a certain limitedtimeframe (e.g., within 1 minute of receiving the code), using theirtoken device. If the codes that are entered by both the sender and theone or more intended receivers match, tokens may be exchanged. However,if the codes that are entered by both the sender and the one or moreintended receivers do not match, tokens may not be exchanged. The longerthe sequence in the code, the more authentication is provided, and themore secure the transaction.

FIG. 12 illustrates a functional block diagram of a portable tokendevice 1210 that includes sound recording capability, in accordance withone embodiment of the present invention. In this embodiment, portabletoken device 1210 is substantially the same as portable token device 210of FIGS. 2 through 7 except that it further includes a digital soundrecorder 1220, a microphone 1230 (e.g., a built-in or externalmicrophone), and an audio file 1240 that is generated by digital soundrecorder 1220 and stored at memory 244.

By use of microphone 1230 and digital sound recorder 1220, ambient soundin the physical environment of token device 1210 may be captured andstored in audio file 1240. Alternatively, the user's voice may becaptured and stored. In either case, the captured audio may be used as anon-spoofable unique identifier and, thus, provides an additional meansfor a unique security or authentication layer.

FIG. 12 also shows a portion of computing environment 100 of FIG. 1 andin one example, User A and User B, who are in substantially the samephysical location, press a record button (not shown) on respectiveportable token devices 1210 and, thereby, capture a certain amount ofsubstantially the same ambient audio content, which is saved inrespective audio files 1240. During the authentication operation that isdescribed, for example, in FIG. 1, the digital audio data from eachdevice may be compared. This comparison may be performed on the sender'sand/or receiver's local portable token device 1210 via, for example,processor 238. Alternatively, the sound comparison may be performed atthe authentication server via, for example, a compare algorithm 1250.Compare algorithm 1250 may be any standard audio compare algorithm, suchas one the compares certain frequencies. In this case, the audio files1240 are passed up to the authentication server database for processingby compare algorithm 1250. Each audio file 1240 may contain a smallpacket of data (e.g., up to about 64 k bytes of data). In one example,multiple filters (not shown) may be provided by which compare algorithm1250 may sample the amplitude of sound at certain frequencies (1 khz, 5khz, 10 khz, 15 khz) as a rapid comparison.

In the case of local authentication, if the audio that is captured onboth the sender's (e.g., User A) and receiver's (e.g., User B) localportable token device 1210 substantially matches, a one-to-one tokenexchange between devices is allowed. In this example, the ability tocapture ambient sound gives context to the exchange process.

Furthermore, the inclusion of a digital sound recorder, such as digitalsound recorder 1220, may provide additional usefulness. For example, thedigital sound recorder may allow a user to capture a voice recording ofspecific comments or notes that the sender and/or recipient may want torecall.

In yet another embodiment, the principles of recording sound that aredescribed in FIG. 12 may likewise apply to recording ambient light. Forexample, each portable token device may include an optical sensor, suchas a photocell device, in order to capture the local ambient light, theintensity of which may be digitized and saved in memory. Again, theambient light data may be compared and utilized in much the same waythat the audio data is compared and utilized. Furthermore, a combinationof both sound and light may be used.

FIG. 13 illustrates a functional block diagram of a token exchangeenvironment 1300, which includes a third party device that may serve asan intermediary device for the exchange of information between two ormore user-subscribers. FIG. 13 also shows token exchange environment1300 in combination with a portion of computing environment 100 ofFIG. 1. In this embodiment, the token exchange environment 1300 includesa third party device 1310 that may be, for example, a standalone device,such as a standalone kiosk. By use of third party device 1310 anyuser-subscriber may “drop-off” his/her token information at third partydevice 1310 where it may be temporarily and securely stored until suchtime that another intended user-subscriber may “pick-up” the tokeninformation. Data may be transmitted between any user's token device andthird party device 1310 via, for example, wireless transmission (e.g.,IR and RF) or wired transmission (e.g., USB connection). In one exampleand referring to FIG. 13, User A drops-off his/her token information ata third party device 1310. At some time later, User B may pick-up UserA's token information and/or drop-off his/her token information inreturn for later pick-up by User A. By use of third party device 1310, aface-to-face interaction between two or more users, such as User A andUser B, is not required. Once a token exchange has occurred via thirdparty device 1310 the authentication and use of the token informationmay be as described, for example, in computing environment 100 of FIG.1.

The information from the user that drops-off his/her information atthird party device 1310 may be tagged (e.g., with certain authorizationcriteria) in such a way as to allow an intended user only to pick up theinformation at third party device 1310. Additionally, there may be atime limit (e.g., within 10 minutes of drop-off) within which theintended receiving user must pick-up the sending user's information.Optionally, once an exchange transaction has occurred via third partydevice 1310, a paper receipt may be printed for the receiving user.Additionally, User A, for example, may return to third party device 1310and verify whether User B has picked up his/her token.

In another embodiment of the invention, the third party device 1310 ofFIG. 13 may be a third user, such as a User C, who passes data betweenUsers A and B.

FIG. 14 illustrates a functional block diagram of a token exchangeenvironment 1400, which includes another third party device that mayserve as an intermediary device for the exchange of information betweentwo or more user-subscribers. FIG. 14 also shows token exchangeenvironment 1400 in combination with a portion of computing environment100 of FIG. 1. In this embodiment, the token exchange environment 1400includes a third party device 1410 that may be, for example, a thirdparty service provider that may serve as an intermediary device for theexchange of information between two or more user-subscribers. Examplesof third party service providers may include, but are not limited to,cell phone service providers, email service providers, and/or GlobalPositioning System (GPS) service providers.

By use of third party device 1410, which may be a third party serviceprovider, any user-subscriber may approve the exchange of informationwith another user-subscriber by contacting third party service providerwho then authenticates the exchange operation. In this example, theportable token device may be a device that has enhanced functionality,such as, but not limited to, sound recording capability, emailcapability, TXT messaging capability, and/or GPS capability. By way ofexample, FIG. 14 shows User A that has a token device 1420A and User Bthat has a token device 1420B, where token devices 1420A and 1420B maybe, for example, a cell phone, PDA device, and/or GPS device.

In one example and referring to FIG. 14, User A and User B wish toexchange information. Both User A and User B may transmit a mutuallyagreed upon code (e.g., via email or TXT message) using his/her tokendevice 1420A to the third party service provider. The code may be usedby the third party service provider in order to authenticate that thereis intended transmittal of information between the users. The code maycontain certain authorization criteria, such as substantially matching(i.e., within practical limits) ambient sound data, timestamp data, GPSdata, and/or ambient RF data (e.g., identifying proximate cellulartowers or other wireless devices). The code may also contain one or bothof the device network ID's (e.g., IP, MAC, or SMS address such that thedevices are able to upload or receive the token ID's over acommunication link that is already authenticated through the Third PartyServer to the Authentication server. Once the third party serviceprovider has verified the relationship between the codes (e.g., valid,matching, or sequenced, etc), the authentication to exchange profileinformation may be as described, for example, in computing environment100 of FIG. 1.

FIG. 15 illustrates a functional block diagram of a computingenvironment 1500 that includes a plurality of service providers, ratherthan one service provider only. In this embodiment, computingenvironment 1500 may include multiple instances of the service providerthat is described with reference to FIGS. 1 through 5. Morespecifically, computing environment 1500 shows a plurality of serviceproviders that are represented by, for example, authentication serversA, B, C, and D. Each authentication server is substantially the same asthe authentication server that is describe with reference to FIGS. 1through 5. By way of example, User A is associated with authenticationserver A and gains access to the service via authentication server A'swebsite (not shown). By contrast, User B is associated withauthentication server D and gains access to the service viaauthentication server D's website (not shown). Because theauthentication servers of the participating service providers maycommunicate one to another via, for example, the Internet 260, User Aand User B may contact one another even though each is using a differentservice provider.

FIG. 16 illustrates a process 1600 of conveying the profile informationthat is associated with a transaction token, rather than displaying theprofile information only. In this embodiment, once the profileinformation of the requestee is received by the requesting user, thisinformation may be displayed on the requesting user's computer and/orconveyed for some other purpose. For example, FIG. 16 shows User Areceiving User B's profile information. User B's profile information maybe displayed on User A's computer. Alternatively, User B's profileinformation may conveyed to some other user and/or entity via, forexample, but not limited to, an email (e.g., initiating an email to UserA), a TXT message (e.g., initiating an TXT message to User A), aninstant message (e.g., initiating a chat session to User A), a telephonecall (e.g., automatically dialing the phone number of User A), a printedor electronic document (e.g., filling in postal information of User A),and so on. A software application and/or algorithm (not shown) for thisfunction may reside on the user's local computer or on a networkcomputer to which the user is connected.

Referring again to FIG. 16, other information that may be conveyed maybe information about a transaction itself, such as sending a digitalcopy of a purchase receipt.

FIG. 17 illustrates a functional block diagram of a computingenvironment 1700 that includes token devices that are associated with acomputer network address, rather than with a user profile. Computingenvironment 1700 may include a LAN 1710, which is a local network thatmay connect multiple computers, such as computers A, B, C, and D.Computers A, B, C, and D may be associated with Users A, B, C, and D,respectively, and token devices 210A, 210B, 210C, and 210D,respectively. In this embodiment, when a user connects his/her tokendevice into his/her computer via, for example, a USB connection, thedevice ID of token device is associated with the hardware address (e.g.,Media Access Control (MAC) address, Internet Protocol (IP) address,Ethernet Hardware Address (EHA), etc.) of the certain computers. Forexample, when User A connects token device 210A into computer A, thedevice ID of token device 210A is associated with the hardware addressor computer A; when User B connects token device 210B into computer B,the device ID of token device 210B is associated with the hardwareaddress or computer B; when User C connects token device 210C intocomputer C, the device ID of token device 210C is associated with thehardware address or computer C; and when User D connects token device210D into computer D, the device ID of token device 210D is associatedwith the hardware address or computer D.

The embodiment shown in FIG. 17 may enable peer-to-peer chattingfollowing an exchange of tokens as long as the token devices areconnected to the user's respective computers, without the need toprovide access to profile information that may be stored by the serviceprovider. In other words, computing environment 1700 allowscommunication between users without exchanging profile information.Alternatively, peer-to-peer communication may be provided by use of anychat application (e.g., AOL, Yahoo, MSN, and Skype). An advantage ofthis embodiment may be that any entity that is connected to LAN 1710 maybe considered a “trusted” entity.

FIG. 18 illustrates a functional block diagram of a telephone-basedtoken system 1800. Telephone-based token system 1800 may include both adata network 260 that is described in FIG. 2 by which multiplecomputers, such as computers A, B, C, and D, are connected and also apre-established communication channel which in this embodiment may be apublic telephone network. Computers A, B, C, and D may be associatedwith Users A, B, C, and D, respectively, and telephones 1810A, 1810B,1810C, and 1810D, respectively. Telephones 1810A, 1810B, 1810C, and1810D may be connected to computers A, B, C, and D, respectively, viamodems 1820A, 1820B, 1820C, and 1820D, respectively. Each modem 1820 maybe, for example, a USB modem. In this embodiment, a certain button oneach telephone 1810 may be pressed in order to send and receive theidentity token over the established voice connection. A telephone-basedtoken system is particularly suited for social networking applications.Telephone-based token system 1800 allows anonymous calling and callcontact permissions that may be based on the online connection betweenuser (the social graph), live and voicemail token exchanges. In thisembodiment, users, such as Users A, B, C, and D, may be talking on thephone and automatically connected in a profile data sharing environmenton their respective Computer interfaces because one user passed aninband token to another user.

Furthermore, as described in FIG. 12, each telephone 1810 may be a sounddevice that is used to capture ambient sound in the physicalenvironment, which may be used as a non-spoofable unique identifier and,thus, provides an additional means for a unique security orauthentication layer.

Referring to FIGS. 1 through 18, in another embodiment of the tokendevice, the portable token device of the invention may be awireless-only token device, a wired-only token device, or a combinationwireless and wired token device.

Referring to FIGS. 1 through 18, while embodiments of the invention havebeen described as both the sending and receiving parties, such as bothUser A and User B, being registered user-subscribers, alternatively, theinvention may provide usefulness with at least one registereduser-subscriber. For example, if User A is registered, whereby User A'sprofile information is stored by service provider, and User B is notregistered, User A may not be able to receive User B's informationfollowing the exchange. However, User B may still be able to receiveUser A's profile information because User B has a device that has anassociated identification. Optionally, User B may choose to registerlater and, thereby, enable User A to receive User B's information.

Referring to FIGS. 1 through 18, in another embodiment of the tokendevice, the token device may include a time component, such as thecapability to provide a timestamp (e.g., time/date stamp) and/or a timerfunction. In one example, the token device may include internal date andtime capability, such as via processor 238, in order to generate atimestamp. Alternatively, the date and time for generating a timestampmay be acquired from a third party, such as from a network entity towhich the token device may be connected. Additionally, the token devicemay include a simple internal timer device that, once triggered and thenstopped, is able to measure and record an elapsed time period for anypurpose.

Accordingly, a timestamp may be attached to any data transmission, suchas to any exchange of tokens, adding further uniqueness to the token IDas the timestamp changes with every transmission. In one example, thetoken devices of two or more users capture a timestamp via any of theabove-mentioned methods. For example, two parties may capturesubstantially the same time and date and generate a token that hassubstantially the same timestamp. The users may then return to theirpersonal computer and exchange tokens based on a substantially matchingtimestamp, within some tolerance. Optionally, the local IP address ofthe network entity from which the date and time is captured may beattached to the timestamp for further matching.

In the case of an internal timer, the internal timer may record, forexample, the elapsed time that User A is in communication with User B,such as during a one-to-one token exchange operation. By monitoring thecommunications protocol, the timer may be activated upon the datatransfer between two devices being initiated and deactivated uponcompletion of the data transfer. The timer value may be appended to theend of the transmission and included in the token exchange data. Theusers may then return their personal computer and exchange tokens basedon a substantially matching timer values, within a practical tolerance.Alternatively, each token device may include a dedicated mechanism forgenerating a time value, such as a dedicated button or switch. In thisexample, two or more users may have to coordinate their actions tosubstantially synchronize (within a practical tolerance) the activationof the dedicated timer mechanism.

Referring to FIGS. 1 through 18, while embodiments of the invention havebeen described as providing one token sending/receiving device for eachseparate user-subscriber, alternatively, one token device may be sharedby two or more user-subscribers without departing from the spirit andscope of the invention. Additionally, while preferably the tokenexchange is at least a two-way exchange, alternatively, the tokenexchange may be one way only, i.e., one user authenticates his/her tokento another user, while the other user does not reciprocate byauthenticating his/her token in return.

Referring to FIGS. 1 through 18, in another embodiment of the tokendevice, the token device may have separate transmit and receive modes.That is, data is sent in one mode and data is received in a differentmode. Alternatively, one user's token device may transmit/receive datausing one type of transmission technology, such as IR or RF, and anotheruser's token device may transmit/receive data using another type oftransmission technology, such as ultrasonic. Certain token devices mayinclude multiple types of transmission capability, such as anycombination of transmission technologies (e.g., broadband, IR, RF,ultrasonic, wired, etc) that are described in FIGS. 1 through 18.

Referring to FIGS. 1 through 18, in another embodiment of the tokendevice, rather than having a fixed ID, token devices may include analgorithm for calculating a new code on-the-fly that may be based, forexample, upon the unique IDs of two devices that are exchanginginformation. In one example, a new unique shared code may be generatedby the combination of User A's ID and User B's ID plus any calculationtherewith in order to create a shared code, such as User A's ID plusUser B's ID multiplied by 3, User A's ID multiplied by User B's ID, andso on. The algorithm for creating a unique code on-the-fly, reduces,preferably eliminates, the need for any user to exchange his/her actualID code with another user. After the operation to generate a new code iscomplete, the actual IDs of the respective users may be deleted from thetoken devices and replaced with the new shared code. In this way, eachuser's code is not being stored on other user's token devices, therebyproviding another level of anonymity.

Referring to FIGS. 1 through 18, in another embodiment of the tokendevice, rather than requiring that each user press his/her transmitbutton, such as transmit button 222 of token device 210, in order toinitiate an exchange of information, each token device may have an“auto-exchange” mode of operation by which exchanges may occurautomatically without user action. For example, the token devices may betransmitting a beacon (e.g., via Wi-Fi, IR, RF, etc) and when two ormore token devices detect one another within their respectivetransmission ranges, the token devices automatically exchange tokens.Optionally, a switch may be provided for enabling/disabling theauto-exchange mode of operation.

Referring to FIGS. 1 through 18, in another embodiment of the invention,instead of the service provider maintaining and storing the userprofiles, the user profiles may be stored at another location (i.e., alocation other than the service provider's location) and/or on aseparate device. For instance, the user profiles may be stored at someother location, such as a hosting location or third party intermediary.A communication link is maintained between the service provider and thedevice and/or entity that are storing the user profiles. By way ofexample, a “profiles database” may be added to the secure data retrievalsystem 800 that is described in FIG. 8. In this example, databases 820and 830 of FIG. 8 are linked to the “profiles database” in order toaccess the user profile data.

Referring to FIGS. 1 through 18, in another embodiment of the invention,instead of exchanging tokens when two or more users physically meet, thetoken exchange process may occur before the users physically meeting,then upon meeting the two or more users may verify the tokens. Forexample, certain users may be planning to attend the same concert,conference, tradeshow, and so on. Prior to the event, the users may, forexample, access the event sponsor's website and download the tokens ofthe other attendees, albeit without specific information. Uponphysically meeting at the event, the users may verify (i.e. throughtoken exchange) each other's identity. In this embodiment, the order ofoperations is modified, instead of (1) meeting in person, followed by(2) exchanging tokens, and followed by (3) exchanging user profiles attheir personal computer, the order of operations may be (1) exchangingtokens, followed by (2) meeting in person, and followed by (3)exchanging user profiles at their personal computer.

Alternatively, the pre-acquired tokens may be locked, and upon meetingat the event, the tokens may be unlocked. Alternatively, the eventsponsor or service provider has the user profiles, which are initiallylocked, and upon meeting the users verify identity and then may returnto their personal computer and use the token to unlock the user profilesof interest.

Referring to FIGS. 1 through 18, in another embodiment of the invention,the device identifications are associated with a second encryption key,instead of associated directly with the user's information. In oneexample, an intermediary encryption key, such as the well-known publickey infrastructure (PKI), may be utilized.

Referring to FIGS. 1 through 18, in another embodiment of the invention,instead of exchanging device identifications, two or more devicesexchange small data files that contain the actual profile information,which may be encrypted. The profile information may be stored in memoryon the individual devices and the service provider website may be usedto provide the key to “unlocking” the received information following anexchange. For example, using the token devices, profile data isexchanged between two or more users. Subsequently, each user accessesthe service provider website in order to unlock the exchange. In thisembodiment, additional security may be provided in that it may not berequired that complete profile information of all user-subscribers bestored on a central server, which is potentially vulnerable to securitythreats. This embodiment of the invention may reduce and/orsubstantially eliminate the need to formally register with the serviceprovider by providing complete user profile information, because allpersonal profile information is managed locally not centrally.

Additionally, this embodiment of the invention may allow each user tocontrol his/her outgoing profile information, such as to provideone-time profile information and/or provide perpetual profile updates.For example, each user may have multiple levels of control, such as to(1) turn on and off the ability of another user to access my his/herprofile, (2) turn on and off the ability of another user to receiveautomatic profile update information, and (3) determine the granulationof their profile that may be seen by other users (e.g., provide acertain email address, physical address, and/or phone number only).

Referring to FIGS. 1 through 18, in another embodiment of the invention,instead of the user having a token device, such as token device 210, theuser has a certain physical item that has a unique Quick Response (QR)code integrated thereon and/or therein. A QR code is a matrix code (ortwo-dimensional bar code) created in Japan that allows its contents tobe decoded at high speed. QR codes that store addresses and URLs mayappear, for example, in magazines, on signs, buses, and business cards.

In this embodiment, user-subscribers may have a QR code on any of theirrespective physical devices, such as on the surface of a cell phone,PDA, business card, keychain, and so on. The QR code may be used as themechanism to provide unique wireless electronic device identification.Any user that has, for example, a camera phone that is equipped with thecorrect reader software may scan the image of the QR code of anotheruser, which, in the context of the invention, may be used for verifyinguser identity. More specifically, stored on the database of theauthentication server are the QR codes of the user-subscribers.Following the physical meeting of two or more users, the QR codes areused for making contact between users via the service provider, insubstantially the same way that the exchange of tokens allows two ormore users to make contact.

Referring to FIGS. 1 through 18, because one of the authenticationvalues in the token values is that the transaction occurred, in anotherembodiment of the invention, a digital autograph may be passed. Anexample of a digital autograph is a digital celebrity autograph. Forexample, because users are apt to share such things in the interface oftheir social network application, the systems and methods of theinvention provide a unique way for the users to display anauthentication from a token service provider that the user really didmeet, for example, his/her favorite celebrity.

Referring to FIGS. 1 through 18, in another embodiment of the invention,the token device identification may be stored on a magnetic stripe. Inthis embodiment, the token device is a one-way device, meaning that itmay act as a sender only device. The magnetic stripe may be, forexample, any magnetic stripe that is capable of storing data, such asthose commonly used on magnetic stripe cards (e.g., credit cards,identity cards, and transportation tickets). The magnetic stripe may beread by physical contact and swiping past a reading head, as is wellknown. In this one-way scenario, the magnetic stripe token deviceconveys access to the user-controlled profile/gateway, rather than aserving as a static identity only. For example, the use of the magneticstripe token device may be used to verify that a certain user-subscribervisited a certain store.

System And Method Implementation

Portions of the present invention may be conveniently implemented usinga conventional general purpose or a specialized digital device, computersystem, server, computer or microprocessor programmed according to theteachings of the present disclosure, as will be apparent to thoseskilled in the art of communication, computer and e-commerce.

Appropriate software coding can readily be prepared by skilledprogrammers based on the teachings of the present disclosure, as will beapparent to those skilled in the software art. The invention may also beimplemented by the preparation of application specific integratedcircuits or by interconnecting an appropriate network of conventionalcomponent circuits, as will be readily apparent to those skilled in theart.

The present invention includes a computer program product which is astorage/recording medium (media) having instructions stored thereon/inwhich can be used to control, or cause, a computer to perform any of theprocesses of the present invention. The storage medium can include, butis not limited to, any type of disk including floppy disks, mini disks(MD's), optical discs, DVD, CD-ROMS, micro-drive, and magneto-opticaldisks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices(including flash cards), magnetic or optical cards, nanosystems(including molecular memory ICs), RAID devices, remote datastorage/archive/warehousing, or any type of media or device suitable forstoring instructions and/or data.

Stored on any one of the computer readable medium (media), the presentinvention includes software for controlling both the hardware of thegeneral purpose/specialized computer or microprocessor, and for enablingthe computer or microprocessor to interact with a human user or othermechanism utilizing the results of the present invention. Such softwaremay include, but is not limited to, device drivers, operating systems,and user applications. Ultimately, such computer readable media furtherincludes software for performing the present invention, as describedabove.

Included in the programming (software) of the general/specializedcomputer or microprocessor are software modules for implementing theteachings of the present invention.

The above description illustrates various embodiments of the presentinvention along with examples of how aspects of the present inventionmay be implemented. The above examples and embodiments should not bedeemed to be the only embodiments, and are presented to illustrate theflexibility and advantages of the present invention as defined by thefollowing claims. Additionally, embodiments of the present invention maycover the operation of a wireless device, including software algorithmsperformed on a wireless device, or the operation of a computer system,including software algorithms performed on a server, database or othercomputer network configuration for implementing backend processing.Based on the above disclosure and the following claims, otherarrangements, embodiments, implementations and equivalents will beevident to those skilled in the art.

1. A wireless face-to-face bilateral communication method between two registered users, of a service provider each having a virtual profile and a token device, comprising: between a sending token device and a receiving token device, transmitting unique electronic transaction tokens between a consenting sending party and a consenting receiving party wherein said transaction tokens are used for a single-use, after-contact, computer-network facilitated access to each party's virtual profile.
 2. The wireless face-to-face bilateral communication method of claim 1, wherein the receiving party is an event organizer, retailer or business premise and the sending party is a business or social invitee, and wherein the receiving token device is stationary and used to receive and process wireless electronic tokens of the invitees.
 3. The wireless face-to-face bilateral communication method of claim 2, wherein the receiving party is a medical services provider and the sending party is a patient.
 4. The wireless face-to-face communication method of claim 1, between a profile requestor and a profile requestee who had previously met at a business or social event, further comprising uploading of said single use transaction tokens to a data server computer system wherein said system authenticates said transaction tokens and said computer system prompts the requestee upon request by requester, to send requestee's virtual profile to requester.
 5. The method of claim 4, wherein either the profile requestor or the profile requestee is a business premises.
 6. The method of claim 4, wherein the virtual profile is granulated.
 7. The method of claim 4, wherein the virtual profile includes information in text, audio, video, images, blogs, website links, schedules, friends, activities, social affiliations, feeds, product description, brochures, coupons, incentive programs, medical records, receipts, purchase history, loyalty points, or items or services for discounted sale.
 8. The method of claim 4, wherein the profile information includes an access to another communication channel—public or private.
 9. The method of claim 4, wherein the profile contains medical or other information and wherein the sending party is a patient in need of healthcare services and the receiving party is a health care provider.
 10. A computer software embedded in a computer readable storage medium, comprising: a module for generating a plurality of unique single-use transaction tokens to be uploaded to wireless token devices; a module for storing profiles for a plurality of users; a module for associating said transaction tokens with the profiles; a module for receiving one profile request associated with a received transaction token uploaded from a wireless token device connected to a user's computer; a module for accessing a profile associated with the received transaction token; and a module for, upon approval by a profile owner, displaying the profile associated with said transaction token to another user's computer.
 11. The computer software of claim 10, wherein the transaction tokens and the profiles are stored in a database accessible over the Internet.
 12. The computer software of claim 10, wherein the step of accessing a profile involves generating a query to a database using the received transaction token, and retrieving the profile associated with the associated token device in response to the query.
 13. A wireless token device for exchanging social or business networking transaction tokens comprising: an external case housing a power supply, a USB interface, a targetable narrow-beam send/receive hardware component, a transmit button, a confirmation LED, processor, a memory, USB transaction software, a selector switch, an internal clock/calendar, and a token counter, wherein exchange of said tokens is accomplished by single button exchanges between a sending party and a receiving party.
 14. The wireless token device of claim 13, wherein the wireless token device is a portable standing-alone device without display capability and with an external ruggedized case, and weighs less than one ounce.
 15. The wireless device of claim 13, wherein the wireless device is embedded in a watch, a cell-phone, a broach, a pendant, a necklace, a ring, an earring, an article of clothing, a clothing label, a wallet or a key-chain.
 16. The wireless device of claim 13, wherein the wireless device is integrated into a smart card.
 17. A method for wireless face-to-face bilateral communication between two registered users of a service provider comprising: generating a plurality of unique electronic single-use transaction tokens each associated with a user-profile stored in a network database; uploading said plurality of transaction tokens into a user's wireless transaction token device; wherein said users exchange said unique single use transaction tokens by single button engagement of said user's token devices to transmit and receive said single use transaction tokens; and wherein said transmission is by means of a directionally targeted narrow electromagnetic beam.
 18. The method of claim 17, wherein said transmission is by means of a short range radio frequency link between parties in very close proximity.
 19. The method of claim 17, wherein said transmission is adapted for secure data retrieval in a business context using non-secure tokens, wherein one of the registered users is in a business premises, and one of the users is an event organizer or health-care provider having a display-capable stationary transaction token device, wherein said stationary token device real time downloads and displays profile associated with received transaction tokens in a real-time manner, and wherein business data associated with an owner of said profile is securely accessed to facilitate a business or payment transaction. 